Кейс "Движок"

Движок — краудфандинговая платформа, предназначенная для благоустройства районов и городов силами местного населения. Пользователи могут предлагать свои идеи по улучшению городской среды, такие как высадка аллеи деревьев или обновление детской площадки. Каждый проект сопровождается описанием, детализированным планом реализации и этапами выполнения.

После публикации проекта открывается сбор средств, в котором могут участвовать жители города или всей страны. Таким образом, каждый может внести свой вклад в создание комфортной и благоустроенной среды. Платформа особенно актуальна для деревень и отдаленных районов, где часто не хватает ресурсов для самостоятельного улучшения инфраструктуры.

Проблемы клиента

Клиент имел дизайн мобильного приложения, но сомневался в его рентабельности и функциональности. Несмотря на наличие фирменного стиля и логотипа, визуальная часть приложения выглядела слабо и не соответствовала требованиям современного рынка.

Кроме того, у клиента уже был сайт, запущенный в формате MVP, на котором проходили первые сборы. Возникла необходимость объединить мобильное приложение и сайт, чтобы на последнем отображать статистику и динамику проектов.

Из-за ограниченных сроков сайт оставался в текущем виде, а нашей команде поручили выполнить редизайн мобильного приложения, чтобы повысить его визуальную привлекательность и улучшить функциональность.
Рисунок - старый дизайн мобильного приложения

Цели проекта

1. Повышение функциональности мобильного приложения
Обеспечить удобство и интуитивность интерфейса, улучшить пользовательский опыт и оптимизировать основные функции приложения.
2. Усиление визуальной привлекательности
Привести дизайн приложения в соответствие с фирменным стилем клиента и современными стандартами UI/UX-дизайна.
3. Поддержка бренда клиента
Укрепить восприятие бренда через продуманный и качественный редизайн, подчеркивающий профессионализм и актуальность решений.
4. Увеличение вовлеченности пользователей
Способствовать росту активности пользователей, повышению числа сборов и их эффективности за счет удобного взаимодействия с приложением.
рисунок - старый ui-kit проекта

Задачи

1. Анализ материалов компании
Провести изучение всех доступных материалов, предоставленных клиентом, чтобы определить, что можно эффективно использовать при редизайне приложения.
2. Изучение сайта и статистических данных
Внимательно проанализировать сайт, включая представленные на нем статистические данные, и на основе этого составить перечень идей для дальнейшей интеграции в мобильное приложение.
3. Разработка полноценного UI-kit
Создать универсальный UI-kit, который станет основой для дальнейшего масштабирования приложения. Поскольку изначально реализовывался только базовый функционал, важно было заложить основу дизайн-системы для удобства дальнейшей разработки и поддержки.
4. Аудит структуры приложения
Провести исследование текущей структуры и функционала приложения, чтобы убедиться, что все ключевые функции учтены. На основе этого подготовить оптимальную структуру и архитектуру мобильного приложения.

Task flows

На первом этапе мы изучили функциональность успешных и удобных в использовании приложений. Анализ охватывал как весь функционал в целом, так и его отдельные элементы. Особое внимание уделялось следующим аспектам:
  • Дизайн и расположение pop-up окон, а также их наиболее удобное применение в различных сценариях.
  • Реакции интерфейса на взаимодействие с элементами, включая действия при нажатии кнопок.
  • Используемые микроанимации и их роль в улучшении пользовательского опыта.
Этот анализ позволил нам определить лучшие практики и идеи, которые могли быть адаптированы и внедрены в редизайн приложения.

Главная

Мы изучили функционал 9-и приложений для сбора идей, как может выглядеть главная страница приложения над которым мы работали. Мы детально изучали весь функционал, прокликивали иконки и выбирали наиболее удачные решения
рисунок - приложение вконтакте
рисунок - вк кофе
Рисунок - инстаграм
рисунок - фейсбук

Проекты

Также нам было важно изучить как выглядят "проекты" в тех или иных приложениях. Процесс был аналогичный. мы подробно изучали весь функционал и доступные функции
рисунок - функционал "проекты"

Профиль

Так же в приложении "движок" изначально планировался личный кабинет или профиль человека, который будет жертвовать денежную сумму или же наоборот собирать средства для благоустройства

Месенджер

Первоначально мы не учитывали функцию сообщений, так как делали первую вариацию приложения, но при дальнейшем обновлении приложения должна была появиться данная функция и возможность перейти в чат. Поэтому с планами на бедующее мы решили дополнительно рассмотреть функционал различных чатов и учитывать его при разработке дизайна

Календарь

Так же дополнительно мы рассмотрели функционал календаря, так как в первоначальной идеи приложения было заложено, что каждому проекту должны присваиваться сроки. Тогда мы еще не до конца понимали будет ли функция календаря в первоначальной версии или только в версии после обновления, но дополнительно мы так же решили ее рассмотреть и учитывать в дизайне

Мудборды

Так же дополнительно мы выделили несколько приложений, где по нашему мнению удачно и лаконично располагался контент, все было просто и понятно для пользователя и мы могли бы позаимствовать идеи в дальнейшем для нашего проекта

Старая Структура

Прежде чем приступать к разработке новой структуры, для начала мы разобрали ту структуру приложений, которая уже имелась, чтобы провести ее аудит и выписать гипотезы об удачных решений и о тех решениях которые сложны для восприятия и могут запутать пользователя

Главная

Главная проблема главной страницы в текущей навигации являлась двойной навигацией. Обычно это наоборот упрощает путь пользователя и уменьшает лишние действия, но в данном случае на каждой странице топ-бар отличался от предыдущей, что могло только сильнее запутать пользователя
рисунок - структура главной старого приложения

Проекты

При первичной визуальной простоте раздел "проекты" был сильно нагромождён различным функционалом и имел неочевидные связи с другими формами приложения, что при регистрации нового проекта могло сильно запутать пользователя и сделать данный процесс трудоемким и не прозрачным
рисунок - структура проектов в старом приложении

Профиль

Изначально мы с командой не хотели сильно менять структуру профиля в отличие от старого дизайна, но когда разобрали имеющуюся структуру поняли, что профилю стоит уделить особое внимание, так как нынешняя структура имела множество неочевидных связей с различным функционалом и было сильно запутана и неочевидна. Так при визуальной простоте, это стало одним из самых запутанных мест.
рисунок - старая структура "профиль"

Мессенджер и календарь

Поскольку данного функционала не было, но он предполагался, мы не могли его рассмотреть в данной структуре, так что мы просто взяли общую структуру рассматриваемых в мудбордах мессенджеров и выписали для себя идеи для дальнейшей реализации

Новая Структура

Разобрав старую структуру и перед тем как приступить к разработке новой мы с командой для себя решили для начала накидать план и идеи на что стоит обратить наибольшее внимание и что следует учесть в первую очередь, прежде чем приступать к разработке
Рисунок - гипотезы и идеи перед разработкой структуры

Регистрация

Первый важный шаг в нашей структуре, которой не было в старой это этап регистрации. Так как изначально предполагался профиль пользователя и работа с денежными средствами в приложении. Для этого стоило учитывать финансовую безопасность человека и его счетов. Именно для этого мы решили разделить приложение на 2 составляющие:
  1. те кто прошел регистрацию и имеют полный функционал
  2. те кто не прошел регистрацию и может просматривать только часть функционала не связанную с финансами
рисунок - новая структура "регистрация"

Главная

Также сильно видоизменилась главная страница, где мы несколькими итерациями постарались максимально детализировать ее функционал и возможность переходы как в карточку проекта та и на другие страницы и настройки и вписать доступы на все страницы приложения и сделать это легким и доступным для пользователей
рисунок - новая структура "главная"

Мессенджер

К моменту проработки новой структуры мы уже обговорили все с клиентом и учитывали такую составляющую как сообщения в структуре приложения и возможность пользователя переходить в чаты и начинать их, а так же переходы на другие настройки и страницы
рисунок - новая структура "мессенджер"

Профиль

Детально расписали весь возможный учитываемый функционал страницы профиля и его содержание, какие элементы и функции доступны и какие настройки пользователь может внести и менять самостоятельно, и какие настройки и функции (ачивки) будут отражаться в приложении но пользователь не сможет их самостоятельно менять
Рисунок - новая структура "профиль"

Итог структуры

Старая структура была практически полностью переработана и в разработке новой мы на старую практически не опирались, так как она имела существенный ряд недостатком. При разработке структуры у команды возник ряд дополнительных вопросов по возможному функционалу, который решался с заказчиком и по мере реализации проекта. Но с учетом этого была разработана совершенно новая детализированная структура на которую команда опиралась при разработке дизайна
Рисунок - гипотезы и вопросы команды

Style guide

Далее весь процесс разработки проводился на английском языке, т.к. приложение разрабатывалось для другой страны, пусть вся команда была русскоговорящая, но все тесты проводились для англоговорящей аудитории.
Для начала мы с командой решили разработать дизайн систему для приложения. По ходу проекта данная система дополнялась, обновлялась и дорабатывалась, но 80% было заложено на первоначальных этапах для удобства дальнейшей разработки
рисунок - интро ui-kit

Цвета

Для проекта мы разработали палитру состоящую из монохромных элементов, так же элементов для интерфейсов (например красный при ошибки или зеленый при успешной отправки) и палитру основанную на фирменном цвете компании
Рисунок - цветовая палитра

Типографика

Так же были разработаны правила для использовании типографики в приложении. За основной шрифт был взят "робото" пусть он и не отличается характерными уникальными чертами, но нам была важнее функциональность, удобочитаемость и возможность перевода на несколько языков мира
Рисунок - типографика

Сетка и отступы

Для разработки приложения мы выбрали 4-х колоночную сетку для более оптимального расположения контента. А также 8-и пиксельные отступы. При разработке данных параметров мы с командой опирались на правила гугл материал дизайна, лишь подробнее расписали правила и дополнительные правила, которые использовали при разработке дизайна приложении и передачи в верстку
Рисунок - сетка и отступы

Кнопки

Для кнопок так же были прописаны правила их использования а так же различные состояния и отражения их в приложении
Рисунок - кнопки

Кнопки социальных сетей, радиботтумы, чекбоксы и пр

Так же все дополнительные элементы были внесены в дизайн-систему и для них были прописаны правила использования, состояния и пр. с учетом размеров и ранее введенных правил
Рисунок - дополнительные элементы

Импуты

Были проработаны различные импуты текстовые и с выпадающим списком, так же с активными состояниями. На рисунке представлены уже конечные варианты импутов, в процессе разработки дизайна приложения они были несколько раз изменены. Выбором такого формата послужили импуты из гугловских форм за их оптимизацию и удобство, а так же что при наличии микроанимации те занимают минимум пространства и остаются информационными с подсказками для пользователя. На разработку конечного вида импутов ушло около 2-х недель
рисунок - импуты

Слайдер, загрузка, дропдаун

Данные элементы появились уже после начала варфрейминга как дополнительные, но так же важные элементы, которые изначально командой не были учтены, но по мере необходимости так же было принято решение включить их в систему и описать правила использования
рисунок - дополнительные элементы

Аватар

Особое внимание было уделено аватару и другим изображениям приложения. Главной нашей задачей тут стало удобство загрузки и взаимодействия с этими элементами. Из-за технических ограничений мы не могли реализовать первоначальную задумку при добавлении новых изображений в приложения, но после мозгового штурма и выстраивания гипотез мы с командой пришли к удобному и лаконичному решению, которое в последствии проверили на пользователях и утвердились в своих догадках и взяли за основу в данный проект.
рисунок - аватар и изображения

Иконки и навигация

Мы не стали опираться на старые иконки приложения и решили разработать те, которые больше подойдут новому приложению
Рисунок - иконки и навигация

General Wireframes

Для начала мы решили не сильно углубляться в соблюдение дизайн-системы, а отрисовать общие каркасы приложения с учетом той структуры, которую мы вывели. Это решение было принято для того, чтобы посмотреть удобство серфинга по приложению и точно ли мы на первоначальных этапах все учли. А так же выявить ошибки и пробелы, которые мы могли упустить и не обхватить
рисунок - первоначальный варфрейминг
По сути мы просто визуализировали нашу структуру в блоки и также связали ее линиями при клике или переходе. Так на первоначальном этапе мы не гнались за точным отображением стиля компании, сколько ставили больше на воспроизведение всех логик и смыслов. Так мы смогли найти несколько моментов и сгенерировать дополнительные вопросы по пробелам, которые обнаружили
рисунок - первоначальный варфрейминг
Подобный подход дал нам понимание где находятся пробелы и дал возможность разделить проект на определенные этапы

Scenario for non registered users

Также основываясь на структуре мы решили углубить и детализировать варфрейминг. И первым этапом стало регистрационный сценарий, то есть регистрация нового пользователя и визуальное отражение
рисунок - регистрация пользователя
Так же в команде появилось несколько гипотез об удобстве регистрации и предоставления информации в приложении. так например спорным моментом стало разделение на: 1 действие = 1 экран или дать пользователям возможность совершить все действия сразу на одном экране
Мы решили проверить данные вопросы на пользователях и провести тестирование

Scenario for I user type

Так были разработаны дополнительные варврейминги для разных типов сценариев, чтобы в дальнейшем проверить нашу гипотезу
рисунок - варфрейминг 1

Scenario for II and III user type

рисунок - варфрейминг 2

Usability testing v1

На всех этапах разработки приложения сразу подготавливались несколько сценариев для тестирования, чтобы сделать приложение максимально удобное для пользователя. Поэтому разработка дизайна очень плотно шла с процессом тестирования и опиралась на данные удобопользования реальных пользователей, а так же правилась и исправлялась в зависимости от того удобно, неудобно и какие сложности у юзеров возникали.
Так за основу мы взяли 3 версии сценариев, которые содержали практически все экраны приложения
Рисунок - тестирование варфрейминга по 3-м сценариям

Сценарий 1 Onboarding & Sign In

Первым сценарием была регистрация пользователей. Мы подготовили кликабельный прототип и наблюдали за пользователем как он проходит путь регистрации. По итогам регистрация пользователя обычно была безболезненной и простой, но при этом у пользователей возникали дополнительные вопросы касаемо безопасности и защищенности своих личных данных, которые мы также выписывали и учитывали
Рисунок - 1е тестирование

Сценарий 2 Notification settings

Одним из проблемных мест стали настройки. Тестинг показал что настройки сложнее всего давались пользователям, они больше всего в них путались и не понимали как вернуться к той или иной настройки. Поэтому после тестирования мы учли все сложности процесса у пользователей и дорабатывали данный аспект
Рисунок - настройки

Сценарий 3 Add a new project

Данный сценарий больше всего вызывал вопросов именно у нас. Так как это была одной из основных функций приложения и изначально нам было непонятно как ее реализовать. Поэтому мы для начала попробовали взять 2 идеи с регистрацией нового проекта. 1-я состояла в 1 экран = 1 действие. вторая заключалась: все действия на 1 экране. По итогам тестирования мы решили отказаться от 2-й идеи, так как пользователям было удобнее производить 1 действие на 1м экране
рисунок - регистрация нового проекта

Промежуточные итоги

Согласно первой версии тестирования мы увидели свои ошибки и учли те моменты, которые вызывают у пользователей больше всего вопросов и в связи с этим начали доработку варфрейминга и подготовку к новому этапу тестирования

Usability testing v2

Мы учли ошибки в дизайне и в подготовке к тестирования, так как после регистрации, например, пользователи недоумевали что ничего дальше не происходило, поэтому мы решили расширить версию кликабельного прототипа и при сохранении всех 3-х сценариев сделать этап перехода более плавным, чтобы глубже погрузить пользователей в приложение
Рисунок - кликабельный прототип

Сценарий 1

Мы детализировали наши прототипы и переработали те места. где у пользователей возникало наибольшее число проблем, а так же дополнили все поп-апами и подсказками, если у пользователя возникала проблема
рисунок - сценарий 1 v2

Сценарий 2

Так же мы детализировали версию настроек и учли все сложности, которые возникали в процессе. Нам данная версия все еще казалась далекой от идеала и у команды были дополнительный пул гипотез, на этот счет, но поскольку обсуждения зашли в тупик, мы решили максимально улучшить вариант нотификейшена и так же протестировать наши гипотезы
рисунок - настройки версия 2

Сценарий 3

Так же дополнительные сложности оставались и в добавлении нового проекта. Мы добавили в конце предпросмотр проекта и после подтверждения и сохранения возможность сразу перейти на опубликованный проект, а также добавили дополнительные экраны с настройками. так теперь например мы убрали у пользователей возможность самостоятельно вводить теги, а предложили выбрать лишь несколько из списка. Это было сделано для того, чтобы ограничить и облегчить дальнейший поиск проектов по тегам
рисунок - добавление проекта версия 2

Usability testing v3

В связи с тестированием и учетом всех сложностей пользователя и ошибок были подготовлены дополнительные экраны для тестирования, которые объединяли в себе все 3 сценария. Данная версия была уже более детализированная и стала неким черновым кликабельным прототипом приложения, где можно было задавать дополнительные вопросы и сценарии
Также была упрощена навигация и началась подготовка к полноценному дизайну на основе всех прототипов

Usability testing v4 и Дизайн

На протяжении всей работы, разработка приложения шла плотно с тестированием. Все вопросы, спорные моменты и гипотезы которые выдвигались во время работы были выписаны и учтены, а также проверены на пользователях, чтобы добиться лаконичного, но при этом функционального интерфейса.
Также перед сдачей проекта был проведен финальный этап юзабилити тестирования, чтобы утвердиться в правильности выбранных решений и подправить все на том этапе, на котором еще это возможно и безболезненно

Сценарий 1

Изначально форма регистрации казалась самой простой, но и в ней возникали свои сложности, например у пользователей на всех этапах возникали дополнительные вопросы, пусть и сама регистрация проходила легко. Поэтому было приято решение дать дополнительные подсказки пользователям чтобы улучшить их первое касание с приложением
сценарий 1 - регистрация версия 4

Сценарий 2

Настройки так е были улучшены и переработанны, а также максимально упрощены. Все дополнительные опции было принято дать микроанимациями, чтобы упростить путь пользователя и возникающие вопросы
рисунок - настройки версия 4

Сценарий 3

Процесс добавления проекта так же был максимально упрощен, чтобы он стал прозрачным для пользователя. не отнимал много времени и был очевиден. Так например появился прогресс бар, чтобы пользователь точно знал сколько шагов ему еще осталось до конца, а сколько он уже прошел
рисунок - добавление нового проекта версия 4

Другие страницы

Так были визуализированы и другие страницы приложения. Весь процесс разработки шел тесно с юзабилити тестированием и мнением самих пользователей о том на сколько им удобно пользоваться теми или иными вариантами решений. Так мы хотели дать максимально простой и удобный продукт, чтобы он сразу был интуитивно понятный для юзеров и у них не возникало никаких сложностей при первом касании или при постоянном использовании
рисунок - страницы приложения

Профиль пользователя

В профиле пользователя основными задачами стало отразить аватар самого пользователя, его проекты (при наличии) и ачивки, которые пользователь мог получить. так при пожертвовании определенной суммы он получал тот или иной рейтинг на сайте и при достижении определенного рейтинга сам мог запускать проекты и собирать на них средства
рисунок - профиль пользователя

Главная страница

Нам хотелось сделать главную страницу информативной, но при этом максимально лаконичной. Для этих целей главным мудбордом для нас служил инстаграм, где с первого касания все было просто и интуитивно понятно. При этом мы смогли лаконично вписать фильтрацию и настройки по поиску проектов, а так же выбор географии, чтобы пользователи выбирали проекты в ближайшем для себе регионе или в том регионе где им интересно
рисунок - главная страница

Поддержка проекта

основой всего приложения была как раз возможность поддержать проект. Так были даны возможности ознакомиться с проектом, а так же пожертвовать нужную сумму на него
рисунок - поддержать проект

Мессенджер

Не смотря на сложную структуру мессенджера, визуально для пользователей это должно было быть просто и удобно, а главное привычно
рисунок - месенджер

Итог

Итогом стало приложение которое было удобно для пользователей, так как на протяжении всего проекта специально разрабатывалось с учетом всех потребностей и сложностей. Нашей основной задачей стало не смотря на все сложные структурные процессы максимально облегчить и упростить визуал приложения, сделать его прозрачным и доступным для каждого